1 INDEPENDENT LOG MANAGER 

2 

3 Technical Field 

4 The technical field generally relates to logging of computer system events 

5 and more particularly to logging managers. 

6 Background 

7 Many computer systems, especially computer network systems in which a 

8 few people manage a large number of machines, include a complete audit trail of 

9 access to records of the configuration events and task events that users ran or 

10 attempted to run. Logging systems record these events in log files that are generally 

1 1 accessible by systems administrators. 

12 Unfortunately, most logging systems are not separate processes that run 

1 3 independently of the rest of the computer system. If the logging system halts 

14 operation, the rest of the system was affected. For example, if daemons were 

1 5 waiting to log a task that the daemons were executing, and the logging system halts 

16 operation, the daemon would have to wait until the logging system operation was 

17 restored. 

1 8 Furthermore, most logging systems require that a configuration or task event 

19 be logged before the configuration or task event is executed. As such, these logging 

20 systems often delay completion of the task or configuration event. Finally, most 

21 logging systems are single-threaded so that the logging system can only manage one 

22 log entry at a time. 

23 A multiple-threaded log manager that queues log entries and frees up the 

24 daemons requesting the writing of the log entries is not found in the prior art. 

25 Likewise, a log manager that runs independently and separately from the other 

26 processes in a computer system is not found in the prior art. Further, a log manager 

27 that does not block the execution of tasks and configuration events on the computer 

28 systems is not found in the prior art. 

29 Summary 

30 A method and apparatus for logging log entries independently and separately 

3 1 from other processes in a computer system is disclosed. An embodiment comprises 

32 a multiple-threaded log manager that queues log entries and frees up the daemons 

33 requesting the writing of the log entries. In an embodiment, a log manager does not 

34 block the execution of tasks and configuration events on a computer system. An 
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1 alternate embodiment comprises a log manager that runs independently and 

2 separately from the other processes in a computer system. 

3 These and other advantages are achieved by a method for logging events 

4 independently and separately from other processes in a computer system, 

5 comprising a consumer initiating an event, wherein the event is a process executed 

6 on a computer system, creating a log entry, wherein the log entry comprises 

7 information that describes the event, requesting that the log entry information be 

8 written to a log file, whereby the consumer surrenders control of the log entry, 

9 pausing execution of the event, and, releasing control of the log entry to the 

10 consumer, so that execution of the event can resume, prior to writing the log entry 

1 1 information to the log file , wherein releasing control of the log entry to the 

12 consumer comprises cloning the log entry, wherein the log entry clone is a copy of 

1 3 the log entry that comprises the log entry information. 

14 These and other advantages are also achieved by a computer readable 

15 medium containing instructions for logging events independently and separately 

1 6 from other processes in a computer system, by a consumer initiating an event, 

17 wherein the event is a process executed on a computer system, creating a log entry, 

1 8 wherein the log entry comprises information that describes the event, requesting that 

19 the log entry information be written to a log file, whereby the consumer surrenders 

20 control of the log entry, pausing execution of the event, and, releasing control of the 

21 log entry to the consumer, so that execution of the event can resume, prior to 

22 writing the log entry information to the log file. 

23 Likewise, these and other advantages are achieved by a computer system 

24 that supports logging events independently and separately from other processes in a 

25 computer system, comprising, a memory, a secondary storage device comprising a 

26 log file, a processor that runs an application, wherein the application comprises a 

27 consumer, wherein the consumer initiates an event that is a process executed by the 

28 processor, creates a log entry comprising information that describes the event, and 

29 requests that the log entry information be written to the log file, a multiple-threaded 

30 log manager, wherein the log manager, independently and separately from other 

3 1 processes, logs events, by receiving the log entry from the consumer, thereby 

32 obtaining control of the log entry and pausing execution of the event, and, releasing 

33 control of the log entry to the consumer, so that execution of the event can resume, 

34 prior to writing the log entry information to the log file. 
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1 Brief Description of the Figures 

2 The detailed description will refer to the following drawings, in which like 

3 numbers refer to like items, and in which: 

4 Figure 1 is a block diagram of a computer system on which an embodiment 

5 of the log manager may be run. 

6 Figure 2 is a block diagram illustrating an embodiment of the log manager 

7 Figures 3a-3b are flowcharts illustrating a method according to an 

8 embodiment of the log manager. 

9 Figures 4a-4c are sequence diagrams illustrating a method according to an 

10 embodiment of the log manager. 

1 1 Detailed Description 

12 A log manager system and method may be used with a computer system that 

13 log events that occur within the computer system. Figure 1 illustrates a computer 

1 4 network system with which the log manager may be used. The computer network 

15 system 10 comprises a ServiceControl Manager ("SCM") 12 running on a Central 

16 Management Server ("CMS") 14 and one or more nodes 16 managed by the SCM 

17 12 on the CMS 14, Together the one or more nodes 16 managed by the SCM 12 

18 make up a SCM cluster 17. A group of nodes 16 may be organized as a node group 

19 18. 

20 The CMS 14 preferably is an HP-UX 1 1 .x server running the SCM 12 

21 software. The CMS 14 includes a memory 143, a secondary storage device 141, a 

22 processor 142, an input device (not shown), a display device (not shown), and an 

23 output device (not shown). The memory, a computer readable medium, may 

24 include, RAM or similar types of memory, and it may store one or more 

25 applications for execution by processor, including the SCM 12 software. The 

26 secondary storage device, a computer readable medium, may include a hard disk 

27 drive, floppy disk drive, CD-ROM drive, or other types of non- volatile data storage. 

28 The processor executes the SCM 12 software and other application(s), which are 

29 stored in memory or secondary storage, or received from the Internet or other 

30 network 24, in order to provide the functions and perform the methods described in 

3 1 this specification, and the processing may be implemented in software, such as 

32 software modules, for execution by the CMS 14 and modes 16. The SCM 12 is 

33 preferably programmed in Java® and operates in a Java environment. See 

34 ServiceControl Manager Technical Reference, HP® part number: B8339-90019, 



1 available from Hewlett-Packard Company, Palo Alto, CA., which is hereby 

2 incorporated by reference, for a more detailed description of the SCM 12. The 

3 ServiceControl Manager Technical Reference, HP® part number: B8339-90019 is 

4 also accessible at http://w^ r vv-,software.hp,com/products/scmgr . 

5 In addition to the SCM 12 software and the HP-UX server described above, 

6 the CMS 14 preferably also comprises a data repository 26 for the SCM cluster 17, 

7 a web server 28 that allows web access to the SCM 12 and a depot 30 comprising 

8 products used in the configuring of nodes, and a I/UX server 32. Although the 

9 CMS 14 is depicted with various components, one skilled in the art will appreciate 

10 that this server can contain additional or different components. In addition, 

1 1 although aspects of an implementation consistent with the present invention are 

12 described as being stored in memory, one skilled in the art will appreciate that these 

1 3 aspects can also be stored on or read from other types of computer program 

14 products or computer-readable media, such as secondary storage devices, including 

1 5 hard disks, floppy disks, or CD-ROM; a carrier wave from the Internet or other 

16 network; or other forms of RAM or ROM. The computer-readable media may 

17 include instructions for controlling the CMS 14 (and/or the nodes 16) to perform a 

1 8 particular method, such as those described herein. 

19 The nodes 16 are preferably HP-UX servers or other servers and they may 

20 be referred to as "managed nodes" or simply as "nodes". The concept of a node 16 

21 is that the mode 16 represents a single instance of HP-UX running on some 

22 hardware. The node 16 may comprise a memory, a secondary storage device, a 

23 processor, an input device, a display device, and an output device. The CMS 14 is 

24 preferably also a managed node 16, so that multi-system aware ("MSA") tools can 

25 be invoked on the CMS 14. 

26 The SCM 12 preferably comprises modules, such as a log manager and a 

27 task manager (shown in Figure 2), that perform specific SCM functions. A user 

28 may access the SCM 12, and the SCM 12 modules, through clients of the SCM 12, 

29 such as graphical user interfaces ("GUIs") and command line interfaces ("CLIs"). 

30 Referring to Figure 1, the SCM 12 preferably supports managing a single SCM 

31 cluster 17 from a single CMS 14. All tasks performed on the SCM cluster 17 are 

32 initiated on the CMS 14 either directly or remotely, for example, by reaching the 

33 CMS 14 using a Web connection 20. Therefore, a workstation 22 at which a user 

34 sits only needs the Web connection 20 over a network 24 to the CMS 14 in order to 
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1 perform tasks on the SCM cluster 17. The workstation 22 preferably comprises a 

2 display, a memory, a processor, a secondary storage, an input device and an output 

3 device. 

4 Object-oriented programming is a method of programming that pairs 

5 programming tasks and data into re-usable chunks known as objects. Each object 

6 comprises attributes (i.e., data) that define and describe the object. Preferably, Java 

7 objects operating in Java Virtual Machines ("JVM") provide the functionality of the 

8 SCM 12. When a user, through a GUI or CLI, wants to access the functionality of 

9 the SCM 12 (e.g., to retrieve, save or modify (e.g., change or delete) persistent data 

10 (e-g-, in Ae data repository 26) or to run a tool on a node(s) or node group(s)), the 

1 1 GUI or the CLI instructs a Java class(es) to be instantiated. Java classes are meta- 

12 definitions that define the structure of a Java object. Java classes, when instantiated, 

13 create instances of the Java classes and are then considered Java objects. Methods 

14 within Java objects are used to get or set attributes of the Java object and to change 

1 5 the state of the Java object. 

16 A tool is an executable that performs a process, and a tool object defines 

17 each tool. A role object defines the role a user may have on a certain node(s) or 

1 8 node group(s), where each role has one or more associated tools that a user with the 

19 role might execute. An authorization object defines the node(s) and node group(s) a 

20 user is authorized to access and what roles the user has on the authorized node(s) or 

21 node group(s). 

22 The objects and classes discussed below are named with a prefix "Mx". The 

23 Mx prefix indicates the application using the objects and classes (the SCM 12) and 

24 is merely exemplary. Indeed, the names of classes, objects and methods discussed 

25 below are exemplary, are not intended to be limiting and are merely used for ease of 

26 discussion. 

27 As shown in Figure 2, a Log Manager 40 is an independent module of the 

28 SCM 12 that is used by SCM 12 clients 42 (e.g., GUIs 92 and CLIs 93) and a task 

29 manager 44, to log configuration and task events that occur within the computer 

30 network system 10. Configuration events include the configuration of objects, such 

31 as creating, deleting and/or modifying user, node, node group, tool, role or 

32 authorization objects and their object attributes. Task events include the running of 

33 tools. The Log Manager 40 preferably manages multiple and concurrent write 

34 requests to a log file 401, localizes log entries (e.g., writes the log entries in the 
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1 local language), writes log entries to the log file 401, handles logic to keep related 

2 log entries together and causes the log file 401 to "roll-over" at a user-specified 

3 size. The log file 401 is preferably a text file (e.g. , an ASCII text file) stored on the 

4 CMS 14 (e.g., in secondary storage). Write requests are generally statements that 

5 an event is happening on the system 10. 

6 The Log Manager 40 preferably is a long-running process with the Log 

7 Managers daemon. The Log Manager 40 is multi-threaded and services a first-in- 

8 first-out ("fifo") queue. One thread of the Log Manager 40 places write requests on 

9 the fifo queue and returns control to a caller (e.g. , a client 42 or the task manager 

1 0 44) so as not to block the caller from continuing the event process. Another Log 

1 1 Manager thread checks the fifo queue for a write request, dequeues the write 

1 2 request, and writes a log entry to the log file 40 1 . 

13 Because the Log Manager 40 uses multiple threads, the performance of the 

1 4 Log Manager 40 and the length of the fifo queue does not affect performance of the 

15 configuration and task events. The configuration and task events do not wait until 

16 after they are logged to execute. Consequently, the Log Manager 40 does not delay 

17 the execution of events that request a log entry. Moreover, since the Log Manager 

18 40 is a separate module of the SCM 12 that runs independently of the other 

19 processes of the SCM 12, the Log Manager 40 will run regardless of whether the 

20 other processes are running, and likewise, the other processes will run regardless of 

21 whether the Log Manager 40 is running. 

22 The Log Manager 40 preferably runs in a JVM on the CMS 14, remote from 

23 the clients 42 and the task manager 44 (the task manager 44 preferably runs on the 

24 CMS 14, but in a different JVM). Accordingly, as shown in Figure 2, the clients 42 

25 and the task manager 44 preferably access the Log Manager 40 through a Remote 

26 Method Invocation ("RMI") interface 46. The RMI interface 46 enables the remote 

27 accessing of the Log Manager 40. 

28 The Log Manager 40 preferably depends on clients 42 and the task manager 

29 44 only so far as the clients 42 and the task manager 44 create valid log entries and 

30 use the Log Manager 40 interface (e.g. , MxLogManagerlfc discussed below) 

3 1 correctly. For example, the clients 42 and the task manager 44 are preferably 

32 responsible for setting a time stamp for the log entries. The Log Manager 40 

33 preferably checks log entries received for errors (i.e., the Log Manager 40 catches 

34 exceptions). For example, the Log Manager 40 may throw an exception (i.e., 
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1 indicate an error) if an unreasonable number (e.g., ten (10) entries from the same 

2 consumer) of log entries contain the same time stamp (e.g. , indicating a possibility 

3 that the clients 42 and task manager 44 are not updating the time stamp). Other 

4 exceptions may indicate that the time stamp is undefined or that an unmatched end 

5 of log is submitted, for example. However, in a preferred embodiment, the Log 

6 Manager 40 does not throw exceptions so as not to interfere with performance of the 

7 configuration or task event. 

8 The Log Manager 40 preferably reads log attributes from a properties file to 

9 run properly and to create and maintain the log file 401 . The log attributes may 

10 comprise: log file size, log file path, log file name, log file extension, host name 

1 1 (e.g. , the CMS 1 4 name) on which the Log Manager 40 is running, port number that 

12 the Log Manager 40 uses for RMI transport, and log fifo queue size. Preferably, 

13 CLI arguments are not required to start the Log Manager 40; instead, the needed 

1 4 parameters are read from the properties file by the Log Manager 40. The needed 

1 5 parameters preferably include the host name, port number, and the log file data. 

16 However, these parameters may be supplied from a CLI or GUI (e.g. , for 

17 development and test purposes), in which case the parameter values override the 

1 8 properties file values. 

1 9 The Log Manager 40 preferably rolls-over the log file 401 (e.g. , locks the 

20 log fifo queue, flushes the log fifo queue, writing the log entries in the log fifo 

21 queue to the log file 401, closes and archives the log file 401 as, for example, 

22 old_logfile and opens a new log file 401) when the log file 401 reaches the log file 

23 size. Again, the log file size is preferably kept in the properties file. Therefore, a 

24 user preferably edits the log file size in the properties file and re-starts the Log 

25 Manager 40 to change the log file size. 

26 In an embodiment, the following Java classes preferably provide the primary 

27 mechanisms for implementing the Log Manager 40 logging capabilities: 

28 MxLogManagerlmpl, MxLogManagerlfc, MxLogManger and MxLog. The 

29 MxLogManagerlmpl class preferably is a Java RMI server and provides access to 

30 the Log Manager 40 logging functionality. The MxLogManagerlfc class preferably 

3 1 provides an interface (/. e. , the RMI interface 46) that enables clients 42 and the task 

32 manager 44 to remotely access the Log Manager 40. Accordingly, the 

33 MxLogManagerlmpl class implements the MxLogManagerlfc interface to provide 
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1 the services necessary for consumers (z. e. , collectively, clients 42 and the task 

2 manager 44) to log events. 

3 The MxLogManager class preferably is a utility class that is a public 

4 interface to the Log Manager 40. A utility class is a class that is only instantiated as 

5 a single instance. The MxLogManager class handles concurrent processing of 

6 operations that request writes to the log file. The MxLogManager class handles this 

7 concurrent processing by ensuring that only a single instance of the MxLogManager 

8 class is instantiated as an object. The MxLogManager preferably enforces its 

9 singleton status by providing only a private constructor and a static method by 

10 which external objects, such as MxLogManagerlmpl, access the MxLogManager. 

1 1 The MxLog class preferably defines the attributes of a log entry, and 

12 provides accessor and mutator methods (e.g., get and set methods) necessary to 

13 modify those attributes. Each log entry is a single instance of the MxLog class 

14 instantiated as an MxLog object. MxLog objects are serializable to allow remote 

1 5 access via the Java RMI mechanism. The consumers of the Log Manager 40 

16 interface "new" MxLog objects (i.e., the consumers instantiate the MxLog class) 

17 and set the attributes of the new MxLog objects specific to the consumer's 

1 8 component (e.g. , the consumer's object). The consumers then present the filled-in 

1 9 MxLog object to the Log Manager 40 via the RMI interface 46. 

20 An MxTaskLog class is preferably a subclass of the MxLog class. The 

21 MxTaskLog subclass preferably exists for task-related events. Preferably, only the 

22 task manager 44 uses the MxTaskLog subclass to log task-related events. The 

23 MxTaskLog subclass preferably comprises additional attributes and accessors 

24 needed for logging tasks. 

25 Figure 3a illustrates a method for logging events 60, according to the present 

26 invention. As shown, the method 60 comprises initiating an event 62, creating a log 

27 entry 64, requesting that the log entry be written 66, releasing control to consumer 

28 68, queuing log entry 70, determining if the log entry is next in the queue 72 and 

29 writing the log entry to file 74, Initiating an event 62 preferably comprises a 

30 consumer (e.g., a client 42 or task manager 44) beginning a configuration or task 

31 event (e.g., beginning the listing of nodes 16 in the SCM cluster 17 or starting the 

32 running of a tool on a target). When an event occurs, the consumer requests that the 

33 event's occurrence be logged. An event is a process executed by the SCM 12 on the 

34 computer system 10. 
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1 Creating the log entry 64 preferably comprises the consumer filling out a log 

2 entry with information that describes the event. In an embodiment, the consumer 

3 fills out the log entry by instantiating the MxLog class to create a new MxLog 

4 object (e.g., my Log), and calling the MxLog accessor and mutator methods to set 

5 the attributes of the MxLog object to describe the event. The attributes preferably 

6 describe the event and include a time-stamp. 

7 Requesting that the log entry be written 66 preferably comprises the 

8 consumer requesting that the log entry information be written to a log, for example, 

9 by submitting the log entry to the Log Manager 40. In an embodiment, the 

10 consumer submits a write request including the log entry to the Log Manager 40 by 

1 1 invoking a loglt Log Manager 40 method and including the MxLog object (e.g. , 

12 myLog) as a parameter of the loglt method invocation (e.g., logManagerioglt ( 

1 3 myLog )). When the loglt method is invoked, the Log Manager 40 may conduct an 

14 error check, attempting to catch any exceptions in the log entry (in the MxLog 

1 5 object). Possible exceptions include a zero time stamp or a repeated time stamp. 

16 When a consumer requests that log entry be written 66, the consumer 

17 surrenders control of the log entry and cannot continue executing the initiated event 

18 until control is released to the consumer. Releasing control to consumer 68 

1 9 preferably comprises releasing control of the log entry and allowing the consumer to 

20 resume executing the initiated event. In an embodiment, the Log Manager 40 

21 clones the MxLog object included loglt method invocation and releases control of 

22 the original MxLog object to the consumer. This allows the consumer to continue 

23 executing the event or to initiate a new event. 

24 Queuing the log entry 70 preferably comprises the Log Manager 40 placing 

25 the log entry in a fifo queue. In an embodiment, the Log Manager 40 provides a 

26 first thread that places the MxLog object (e.g. , myLog) on a fifo queue that the Log 

27 Manager 40 maintains. The fifo queue pushes log entries (e.g., MxLog objects) out 

28 of the queue on a first in, first out basis, 

29 Determining if the log entry is next in the queue 72 preferably comprises the 

30 Log Manager 40 determining if the current log entry is the oldest log entry in the 

3 1 fifo queue. In an embodiment, when the current MxLog object (e.g. , myLog) is the 

32 oldest MxLog object in the fifo queue, the fifo queue may indicate that it is the 

33 current MxLog object's turn to be logged. 
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1 When the log entry is next in the queue, the Log Manager 40 preferably 

2 retrieves the log entry from the fifo queue, localizes the log entry and writes the log 

3 entry information to a log file. Accordingly, in an embodiment, writing the log 

4 entry 74 comprises the Log Manager 40 providing a second thread to get the MxLog 

5 object (e.g, myLog) off of the queue, localizing the MxLog object and writing the 

6 MxLog object to the log file 401. Writing and localizing the MxLog object to the 

7 log file 401 preferably comprises the Log Manager 40 getting the log information 

8 from the MxLog object, mapping the log information to strings in the local language 

9 (e.g., English) and writing the log information strings as ASCII text in the log file 

10 401. 

1 1 The Log Manager 40 preferably keeps separate, but related task event log 

12 entries together in one log file 401 and preferably will not roll over the log file 401 

13 such that these separate, but related log entries would be split up (i.e., one in the log 

14 file 401 and one in an archived log file). Consequently, if the event is a task event, 

15 the method for logging task events 60' may comprise additional steps, as shown in 

16 Figure 3b. The method for logging task events 60' preferably comprises initiating a 

17 task event 62', starting a log transaction 63, creating a log entry 64, requesting that 

18 the log entry is written 66, releasing control to consumer 68, queuing log entry 70, 

19 determining if the log entry is next in the queue 72, writing the log entry 74, 

20 repeating steps 64-74 for additional log entry(ies) 76, determining if task event is 

21 ended 78, and terminating the log transaction 80, 

22 Starting a log transaction 63 preferably comprises a consumer sending a 

23 message that a sequence of related task log entries are to be sent. In an 

24 embodiment, a task manager 44 tells the Log Manager 40 that a sequence of related 

25 task log entries will be sent by calling a Log Manager 40 method 

26 startLogTransaction(). The Log Manager 40 preferably keeps track of the number 

27 of startLogTransaction() method calls (starts) and of corresponding 

28 endLogTransaction(O) method calls (ends). When the number of starts and ends 

29 matches, the Log Manager 40 may roll-over the log file, since no related log entries 

30 will be split up. 

3 1 Generally, there are log entries corresponding to the initiation of a task event 

32 and the end of a task event. There may also be additional, intermediate log entries 

33 during execution of the task event. Accordingly, repeating steps 64-74 for 

34 additional log entry(ies) preferably comprises the task manager 44 creating and 
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1 submitting an additional log entry or additional log entries, and the Log Manager 40 

2 processing the additional log entry or log entries, as described with reference to 

3 Figure 3 a. 

4 Determining if task event is ended 78 preferably comprises determining if 

5 the task event has completed or if the task event has failed to complete {e.g., the 

6 task manager 44 crashed while executing the task). If the task event has completed, 

7 the task manager 44 preferably terminates the log transaction 80. Consequently, in 

8 an embodiment, terminating the log transaction 80 comprises the task manager 44 

9 calling the Log Manager 40 endLogTransaction() method after the last task log 

1 0 entry in the sequence. Termination of the log transaction indicates that a sequence 

1 1 of log entries associated with the task event has ended. As stated above, a matching 

12 number of starts and ends indicate that the log file 401 may be rolled over. If a 

13 certain amount of time has passed without receiving an endLogTransaction, the Log 

14 Manager 40 preferably assumes that the task event has failed to complete and rolls- 

1 5 over the log file 40 1 . 

16 Figures 4a-4c are sequence diagrams illustrating a sequence of method calls 

17 for logging an event according to an embodiment of the present invention. Figure 

18 4a illustrates a series of method calls for creating a log entry and submitting the log 

19 entry to the Log Manager 40. These method calls correspond to step 64 and step 66 

20 of the method shown in Figure 3 a. The sequence diagram 90 includes boxes 

21 representing a client GUI 92, the MxLog implementation class 94 and the 

22 MxLogManager utility class 96, which represents the Log Manager 40. Descending 

23 from the representations of the GUI 92, MxLog class 94 and MxLogManager class 

24 96 are vertical time-lines 98 that represent the period of execution of the GUI 92, 

25 MxLog class 94 and MxLogManager class 96. Extending from invoking time-lines 

26 98 to target time-lines 98 are method call lines 100 that represent methods invoked 

27 by the GUI 92 on a target class (i.e., the MxLog class 94 or the MxLogManager 

28 class 96). Also shown are notation boxes 102, which include comments regarding 

29 certain method call lines 100. 

30 After the GUI has initiated an event (e.g., a configuration event), the GUI 

3 1 invokes a constructor (e.g. , MxLog) in the MxLog class 94 to create a new MxLog 

32 object, as shown by a "new()" call line 100. When populated with data, the new 

33 MxLog object will be the log entry submitted to the Log Manager 40. As shown by 

34 the associated notation box 102, the GUI may issue a method call new MxLog 
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1 (userName, objectName) when the user 'userName' wants to create a log entry 

2 about a configuration of an object identified by 'objectName.' For example, the 

3 object being configured may be a user, node, node group, tool, role, authorization or 

4 other type of object. 

5 A setMsg() method call line 100 indicates that the GUI 92 invokes a MxLog 

6 class 94 method setMsg() that preferably sets the text of the new log entry. For 

7 example, as shown by the associated notation box 102, the GUI could issue a 

8 method call setMsg("Added as a trusted user"), which would set "Added as a 

9 trusted user" as the text of the new log entry. Preferably, the text of the log entry 

10 describes the event (e.g., a configuration event adding a user as a trusted user). 

11 A set TimeStamp() method call line 100 indicates that the GUI 92 invokes a 

12 MxLog class 94 method setTimeStamp() that preferably sets the new log entry time 

13 stamp. The GUI 92 preferably provides the actual time for the time stamp. 

14 The GUI 92 may invoke additional or different MxLog class 94 methods, 

1 5 depending on the data that is included in the new log entry. After the new MxLog 

16 object has been constructed and populated (i.e., the log entry has been completed), 

17 the GUI 92 invokes a MxLogManager class 96 method to submit the new MxLog 

18 object to the Log Manager 40. This method invocation is shown by the logIt() 

19 method call line 100. The parameter included in the logIt() is the name of the new 

20 MxLog object (e.g., myLog). The logIt() method submits the new MxLog object to 

21 the Log Manager 40 and requests that the Log Manager 40 log the new MxLog 

22 object (i.e., requests writing of the new log entry to the log file 401). 

23 Figure 4b illustrates a series of method calls for queuing and de-queuing the 

24 log entry and writing the log entry to the log file 401 . The sequence diagram 1 10 in 

25 Figure 4b includes boxes representing the MxLogManager class 96, representing 

26 the Log Manager 40, the MxLog class 94, a Java Property Resource Bundle utility 

27 1 12 and a MxLogQueue class 114. The MxLogQueue class 1 14 is an interface to 

28 the log queue maintained by the Log Manager 40. As with the sequence diagram 90 

29 in Figure 4a, the sequence diagram 110 includes time-lines 98, method call lines 

30 1 00 and a notation box 1 02. 

3 1 The notation box 102 indicates that the Log Manager 40 has received the log 

32 entry and a request to write the log entry to the log file 401 (i.e., the 

33 MxLogManager class 96 method loglt has been invoked, as shown in Figure 4a). 

34 When the Log Manager 40 receives the log entry (i.e., the MxLog object), the 
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1 MxLogManager class 96 may execute catch exceptions code to check for errors. 

2 For example, the MxLogManager class 96 may check to ensure that the log-entry 

3 time stamp is non-zero or that the time stamp is not a repeated time stamp. If an 

4 error is found, the MxLogManager class 96 may execute error condition code to, for 

5 example, return the log entry to the GUI 92 so that the error is corrected. 

6 If no errors are found, the MxLogManager class 96 preferably clones the 

7 MxLog object. The clone() method call line 100 indicates that the MxLogManager 

8 class 96 makes a self-referential method call to invoke a MxLogManager class 96 

9 method. Cloning of the MxLog object returns control to the GUI 92 so that the GUI 

10 92 can continue to execute the event (e.g. , the configuration of a new user object). 

1 1 The enque() method call line 100 indicates that the MxLogManager class 96 

12 invokes a MxLogQueue class 114 method to place the cloned MxLog object in the 

13 queue. The enque() method call line 100 also represents a first thread of the Log 

14 Manager 40 that the Log Manager 40 generates to place log entries in the queue. 

1 5 As stated above, the Log Manager 40 is preferably a multiple threaded process. The 

1 6 cloned MxLog obj ect name (e. g. , myLog) is preferably included as the enque() 

17 method parameter. Java synchronization features preferably handle queue 

18 concurrency issues (e.g., two log entries are sent to the Log Manager 40 for logging 

1 9 at the same time, as indicated by their time stamps). 

20 The dequeue() method call line 100 indicates that the MxLogManager class 

21 96 invokes a MxLogQueue class 114 method to remove a cloned MxLog object 

22 from the queue. Preferably, the queue is a fifo queue and the dequeue() method will 

23 remove the oldest log entry from the queue. The dequeueO method call line 100 

24 also represents a second thread of the Log Manager 40 that the Log Manager 

25 generates to remove log entries from the queue. The Log Manager 40 may keep 

26 track of the oldest log entry, and include the name of the oldest log entry as the 

27 dequeue method parameter. Alternatively, the queue itself determines the oldest log 

28 entry and returns it when the dequeue() method is invoked. 

29 When the log entry is returned, the Log Manager 40 writes the data 

30 contained in the log entry to the log file 401. Preferably, this comprises the 

3 1 MxLogManager class 96 invoking MxLog class 94 methods to retrieve data from 

32 the MxLog object returned from the queue. The getMsg() method call line 100 

33 illustrates an invocation of the MxLog class 94 method that accesses the text of the 

34 log entry and returns the text to the Log Manager 40. Likewise, the getUserNameQ 
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1 method call line 100 illustrates invocation of the MxLog class 94 method that 

2 accesses the user name of the user that initiated the event that is described by the log 

3 entry and returns the user name to the Log Manager 40. The getObjectName() 

4 method call line illustrates an invocation of the MxLog class 94 method that 

5 accesses the object name of the MxLog object. 

6 The setContext() method call line 100 illustrates invocation of the MxLog 

7 class 94 method that sets a context of the log entry. The context preferably 

8 comprises the language in which the log entry will be written. The normal default 

9 context is English. If the Log Manager 40 is used in a system 1 0 that requires a 

1 0 different language, the context may be set to the different language (e.g. , Japanese) 

1 1 and the log entry will be written in that different language. 

12 The toContextMessage() method call line 100 illustrates invocation of the 

1 3 Property Resource Bundle Java utility 112 method that writes the text of the log 

14 entry (i.e., the strings contained in the MxLog object attributes) to the log. The 

1 5 language used is determined by the context set by the preceding setContext method. 

16 The toContextMessage() method takes the string attributes of the MxLog object 

17 passed with invocation of toContextMessage() method and writes these strings in 

18 the log file 401. 

19 Figure 4c illustrates a series of method calls, generally corresponding to 

20 Figure 3b, for creating task log entries and submitting task log entries to the Log 

21 Manager 40 when a task is performed. A task is the running of a tool with targets. 

22 The sequence diagram 120 shown in Figure 4c includes boxes representing an 

23 MxTaskManager utility class 122, which represents the task manager 44, a 

24 MxTaskLog implementation class 124, which preferably is a sub-class of the 

25 MxLog implementation class 94, and the MxLogManager utility class 96, which 

26 represents the Log Manager 40. The startLogTransaction() method call line 100 

27 indicates that the MxTaskManager class 122 is executing a task and is invoking a 

28 MxLog Manager 96 method to start a log transaction. Preferably, all related log 

29 entries in a log transaction (/. e. , after the start of a log transaction and prior to the 

30 end of a log transaction) are kept together in the current log file 401 . As discussed 

31 above, the Log Manager 40 preferably keeps track of startLogTransaction() method 

32 invocations ("starts") and endLogTransaction() method invocations ("ends") and 

33 will only roll-over the log file 401 when the number of starts and ends are equal. 
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1 This roll-over rule prevents the separation of related log entries into current and 

2 archived log files. 

3 The new() method call line 100 indicates that the MxTaskManager class 122 

4 invokes a MxTaskLog classl24 constructor method (e.g. , MxTaskLog) to construct 

5 a new MxTaskLog object. When populated with data, the new MxTaskLog object 

6 will be the task log entry submitted to the Log Manager 40. As shown by the 

7 associated notation box 102, the task manager 44 may issue a method call new 

8 MxLog (userName,taskID,target,toolName) when the user 'userName 5 wants to 

9 create a task log entry about the task identified by 4 taskID', which is executed on a 

10 target node(s) or node group(s) identified by 'target 5 with the tool 'toolName.' A 

1 1 tool in the SCM 12 performs various tasks on a target node or node group, and may 

12 perform tasks on multiple nodes or node groups when the tool is a multi-system 

13 aware tool. Preferably, the first MxTaskLog object is a task log entry that indicates 

1 4 that the task has started. 

15 A set TimeStamp() method call line 1 00 indicates that the MxTaskManager 

16 class 122 invokes a MxTaskLog class 124 method setTimeStamp() that preferably 

17 sets the new log entry time stamp. The MxTaskManager class 122 preferably 

1 8 provides the actual time for the time stamp. 

19 The MxTaskManager class 122 may invoke additional or different 

20 MxTaskLog class 124 methods, depending on the data that is included in the new 

21 task log entry. After the new MxTaskLog object has been constructed and 

22 populated (i.e. , the task log entry has been completed), the MxTaskManager class 

23 122 invokes a MxLogManager class 96 method to submit the new MxTaskLog 

24 object to the Log Manager 40. This method invocation is shown by the logIt() 

25 method call line 100. The parameter included in the logIt() is the name of the new 

26 MxTaskLog object (e.g. , myTaskLog). The logIt() method submits the new 

27 MxTaskLog object to the Log Manager 40 and requests that the Log Manager 40 

28 logs the new MxTaskLog object (i.e. , requests writing of the new task log entry to 

29 the log file 401). 

30 As the task is executed and completed, the task manager 44 preferably 

3 1 creates one or more additional task log entries. Rather than creating a new 

32 MxTaskLog object for each additional task log entry, the task manager 44 may 

33 simply modify the attributes of the MxTaskLog object created above and resubmit 

34 the modified MxTaskLog object to the Log Manager 40. Accordingly, the 
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1 setLogTaskResult method call line 1 00 indicates that the MxTaskManager class 122 

2 invokes a MxTaskLog class 124 method to set a MxTaskLog object attribute that 

3 indicates the result of the task (e.g. , whether a success, failure, in progress, some 

4 failures, canceled or killed). In the example sequence diagram 120 shown, the task 

5 is a success. Consequently, as shown by the associated notation box 102, the 

6 MxTaskManager class 122 invoked the MxTaskLog class 124 method 

7 setLogTaskResult(MX_SUCCESS). 

8 The setLogEvent()method call line 100 indicates that the MxTaskManager 

9 class 122 invokes a MxTaskLog class 124 method to set a MxTaskLog object 

10 attribute that indicates what type of event is being logged. For example, the event 

1 1 logged may be the completion of the task (/. e. , done), the start of the task (i. e. , start) 

12 or the completion of an intermediate step (e.g., file copies). In the example 

13 sequence diagram 120 shown, the task is done. Consequently, as shown by the 

14 associated notation box 102, the MxTaskManager class 122 invoked the 

1 5 MxTaskLog class 124 method setLogEvent(MX_DONE). 

1 6 As with the previous entries shown above, the task manager 44 preferably 

1 7 sets the time-stamp of the present task log entry (i. e. , the modified MxTaskLog 

18 object). Consequently, the setTimeStamp() method call line 100 indicates that the 

19 MxTaskManager class 122 invokes the MxTaskLog class 124 method 

20 setTimeStampO to set the new log entry time stamp. 

21 After the MxTaskLog object has been modified, the MxTaskManager class 

22 122 invokes the MxLogManager class 96 logIt() method to submit the new 

23 MxTaskLog object to the Log Manager 40. The logIt() method submits the 

24 modified MxTaskLog object to the Log Manager 40 and requests that the Log 

25 Manager 40 logs the modified MxTaskLog object (i.e., requests writing of the new 

26 task log entry to the log file 401). In the example shown, as indicated by the 

27 associated notation box 102, the logIt() method is invoked to log that the task is 

28 completed. 

29 The endLogTransaction() method call line 100 indicates that the 

30 MxTaskManager class 122 invokes the MxLogManager class 96 method to end the 

3 1 current log transaction. As discussed above, when the number of starts equals the 

32 number of ends (e.g. , after the endLogTransaction() method is invoked) the Log 

33 Manager 40 may roll-over the log file 40 1 . 
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1 While the Independent Log Manager has been described with reference to 

2 the exemplary embodiments thereof, those skilled in the art will be able to make 

3 various modifications to the described embodiments without departing from the true 

4 spirit and scope of the Independent Log Manager. The terms and descriptions used 

5 herein are set forth by way of illustration only and are not meant as limitations. 

6 Those skilled in the art will recognize that these and other variations are possible 

7 within the spirit and scope of the Independent Log Manager as defined in the 

8 following claims and their equivalents. 
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